Open source commercial offerings (or products) often include source code of software modules that are submitted by different contributors. Source code is referred to as “upstream” if the owner (likely the original author) or maintainer of a software module accepts patches (or modifications) to the source code sent to the owner by other entities (e.g., a reviewer of the software module). A patch may correct certain perceived defects in the software module. The owner may or may not accept the submitted patch. If accepted, the owner includes the upstream patch in a database (e.g., an upstream GIT tree) that the owner uses to store the software module and assume the responsibility to maintain the patch. However, if rejected, the patch is non-upstream, and the developer of the patch is responsible for maintaining and distributing the patch.
Owners of software modules refuse patches from other entities for various reasons. For example, the open source product may use a different approach to turn on kernel configuration options than the owner of the software module allows. In another example, the owner of the software module does not allow a policy in the kernel area. An inadmissible policy is “crashkernel=auto” which is a policy that may automatically reserve the memory that is used for crash dump. The owner could consider that this policy for the software module is inadmissible.
In a major open source commercial offering release, the kernel itself may include hundreds of patches that are not upstream, and the whole product may include quite a bit more of code patches that are not upstream.